Hybrid Access (HA) combines at least two different network links with the same or different network technology, for example it combines the access over the fixed network 124 with the access over the cellular network 121. FIG. 1 shows a typical scenario for HA but can also be implemented as an over the top (OTT) solution. The HA client 101 has at least two access interfaces, one for example for Digital Subscriber Line (DSL) access 124 and another one for example for access to the Long Term Evolution (LTE) network 121. The considerations on the HA algorithms 102 are focused on a distributed client-server solution with client functionality in the residential gateway 101 and server functionality (HA Server 103) in a data center at the network of the operator 210 or in the public Internet 130. The Multipath Transmission Control Protocol (MPTCP) according to RFC 6824: A. Ford, C. Raiciu, M. Handley, and O. Bonaventure, “TCP Extensions for Multipath Operation with Multiple Addresses,” RFC, no. 6824, January 2013“ can be applied for HA. MPTCP is a new proposed standard for a transport layer protocol as an extension to the regular Transmission Control Protocol (TCP). MPTCP, as depicted in FIG. 2 depicting two endpoints E1, 201 and E2, 203 connected by MPTCP 202, enhances network performance, especially if the available throughput on one interface is relatively lower than the application's demand and there is the possibility to use multiple (n) interfaces to maximize the overall output.
Since the Linux kernel implementation of the MPTCP, resource bundling on multihomed devices has come to be one step closer to ubiquitous. However, bundling HA networks with MPTCP faces a challenge from connectivity issues, should the primary chosen route fail to establish a connection to the desired endpoint. MPTCP by default relies on the network layer's routing functionality to make sure that it can build an initial subflow, to be in a position to exploit multiple routes to the same destination.
MPTCP enables making use of multiple interfaces and/or paths (IP addresses and port numbers) for a single connection. By default/design a TCP connection is bound by a four tuple of IP addresses and port numbers, implying that no more than one pair of IP addresses can be used at a time. When an application desires to communicate with a remote host using TCP as a transport layer protocol, it creates a socket, which is identified by a pair of IP addresses and a pair of port numbers. These pairs are unique that addition of any pairs to this communication is impossible. To overcome this limitation MPTCP was developed to allow TCP make use of multiple pairs of IP addresses and/or port numbers for a single communication, while keeping the application layer abstraction of single pairs.
This abstraction of single pair IP address and port numbers is achieved with the concept of initiating and establishing a first main TCP flow. This main flow is used as the single point of exchange between the application and TCP and enables data communication (switch connection in “established” mode). That is, MPTCP has added an extra layer of abstraction where it can aggregate different subflows as a single one, as if the data received from all subflows was received via the main flow only (from the application's point of view). This concept requires that this flow be the first to be created while establishing additional connections. The main flow is referred to as “primary subflow”, and any further addition of flows (called additional/subsequent subflows) to this connection should follow only after a successful establishment of this primary subflow.
To start a connection MPTCP sends a TCP like SYN message that has an option to ask/offer MPTCP capability, called MP_CAPABLE. The receiver on the other hand has the option either to reply with an MP_CAPABLE SYN/ACK packet and form an MPTCP enabled connection or with a regular TCP SYN/ACK message telling the sender to fall back to a regular TCP connection. In the former scenario, the two connecting parties will exchange key strings from which a token will be generated to enable further flow establishment and securely join the pool of MPTCP subflows belonging to a single connection.
The phase of connection establishment relies on the functionality of its path manager which in turn relies on the network layer routing module. By design Linux' routing subsystem provides list of available routes to the kernel modules that require it. Moreover, under normal circumstances, a Linux machine can have only one default route at a time, except that load balancing functionality is desired. This implies that, if a route designated as default becomes inaccessible, then the routing functionality will not be able to serve the connection request coming from the application layer destined to unknown routes. Even in the case of multipath routing, as soon as a route configured as one of the default gateways dies, the entire multipath routing rule is deleted leaving no default route at all. This problem could be solved only if the interface in question is put down, so that device status change messages trigger the routing module to remove it from the default route and there is an independent process that promotes an alternative interface as default route. There are various ways of achieving this goal, but none is immune against introducing delay while establishing a connection and consuming extra resources.
This problem is further exacerbated if the connection initiating multihomed device is connected to a router that has no connection to the other end. That is, if the network interface connected to such a router is set as default route, MPTCP will not get a timely feedback that desired host is not reachable on this route and should resort to alternative paths. Rather it will wait until RTO expires and gives up on connection attempts. This is a dead end scenario that could be experienced by mobile devices having both cellular and wireless connectivity. On such devices, by default, wireless networks (WLAN) are set as default routes, whenever available for cost reasons.
Network vendors providing hybrid access solution could experience even a worse situation if their resource bundling solution at home gateway uses MPTCP with a proxy solution. That is, when a single homed client initiates a connection to the internet, the home gateway will intercept that connection, letting the client believe it is connected to its desired destination. But since the home gateway's default route has lost connection to the internet, the home gateway will never be able to initiate a second subflow except there is a mechanism to correct this setback.
A second worse scenario for network vendors providing hybrid access solution is when a multihomed client connects to such a gateway (putting aside the question whether such a client could ever be able to exploit its multiple interfaces at the same time in such constellation). In this case, even if the client has a second network interface, which is capable of accessing the internet, it will never be able to reach its connection partner as it will have a primary subflow bound to the home gateway only. Detecting and correcting such a failure is even more challenging than the former scenario.